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Abstract 

The use of weakest-precondition predicate transformers in the 
derivation of sequential, process-control software is discussed. 
Only one extension to Dijkstra’s calculus for deriving ordinary 
sequential programs was found to be necessary: function-valued 
auxiliary variables. These auxiliary variables are needed for reason- 
ing about states of a physical process that exist during program tran- 
sitions. 


1. Introduction 

For the past few years, we have been exploring the use of assertional 
reasoning in the construction of process-control software. Our intent was to 
employ an existing method, perhaps with a few extensions, and systemati- 
cally derive process-control programs from specifications. Use of an existing 
method had both a scientific and a pragmatic motivation. The scientific 
motivation was based on our expectation that the difficulties we encountered 
by using an extant method would provide insights into what distinguishes 
- 
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process-control programs from ordinary sequential and concurrent programs. 
The pragmatic motivation was that extending a well understood method was 
likely to be easier than developing a new one. 

Our investigations have been structured as a series of experiments. 
Each experiment is based on a simple process -control problem that (we feel) 
epitomizes some aspect of process-control programming. We started with 
the simplest process-control problem imaginable — a sequential control- 
program running on a single, fault-free processor. By reading sensors and 
writing to actuators, this program controls an on-going physical process. 
Solving such a problem requires reasoning about control-program execution 
times, something that has long been considered an integral part of process- 
control programming. We are well aware, however, that any conclusions 
from this experiment would have to be regarded as tentative. By considering 
a sequential control-program, problems arising due to resource contention are 
avoided; and by assuming a fault-free processor, complications associated 
with implementing fault-tolerance are being ignored. 

Simplifying assumptions not withstanding, our first experiment did 
lead to some insights about the use of assertional reasoning in writing 
process-control programs. These insights are the subject of this paper. In 
section 2, we describe extensions to Dijkstra’s weakest-prccondition calculus 
[2] [3] that we found necessary for deriving sequential process-control pro- 
grams. Section 3 illustrates the use of these extensions and the calculus by 
giving an example derivation of a control program. Conclusions appear in 
section 4. 

2. Using Weakest Preconditions with Physical Processes 

Process-control problems are often specified in terms of restrictions on 
permissible states of some physical system. By setting actuators to manipu- 
late the process being controlled, a control program ensures that none of 
these proscribed states is ever entered. The actions of the control program 
are, therefore, closely linked to the state of the physical process being con- 
trolled. Consequently, when deriving a control program, it is necessary to 
reason about both the program state and the state of the physical process 
being controlled. 

Assertional methods for deriving programs are based on manipulating 
logical formulae, called assertions, that characterize sets of program states. 
One way to employ assertional methods in the design of a process-control 
program is to augment the program state space so that it includes information 
about the state of the physical process being controlled. Doing so, however, 
requires extending the rules used to reason about program execution, as fol- 
lows. 

(1) While a program statement is executed, changes occur to the state of 
the physical process being controlled. Rules characterizing the 
effects of program execution must be modified to reflect these other 
state changes. 
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(2) Statements whose execution involves interaction with sensors and/or 
actuators must be axiomatized as rules relating states before, during, 
and after execution. 

The remainder of this section discusses these extensions. 

2.1. Reality Variables 

The state space of physical system is usually defined by a collection of 
state components, each of which is indexed by some independent (physical) 
parameters. For example, the state of a railroad train at a time T can be 
characterized by its position X(T), its speed V(T), and its acceleration A(T). 
Note that the choice of time as the independent parameter is arbitrary. If its 
velocity is always greater than 0, then a train at position X could equally well 
be described by time T(X), speed V(X), and acceleration A(X). As physicists 
learned long ago, quantities that are convenient for the task at hand should be 
selected as the independent parameters. 

The state space of a program can be augmented to include the state of a 
physical process. For each state component Q,, we add to the program state 
space a function-valued program variable q„ called a reality variable. 1 Each 
reality variable replicates (in the program’s state space) information about a 
physical system during program execution. Initially, the domain of a reality 
variable q, will be empty; as the independent parameter for Q, changes, 
the domain of q t is extended to include the values over which P, has ranged. 
Reality variables are entirely fictional. They allow us to describe and reason 
about the state of a physical system by using assertions, but they are not actu- 
ally maintained in memory. Thus, they are a form of auxiliary variable [1]. 

In order to define and manipulate expressions involving function- 
valued program variables, like reality variables, it will be convenient to have 
some notation. Following [2], given a function / with domain domif), the 
function expression 

<f; xeD:g(x)) 

is defined to be a function whose domain is dom(f)KjD and whose value at 
any point a is g(a) if a € D and /(a) otherwise. As a rotational convenience, 
we define: 

< f : xeD.g(x); xeD’:h(x)) = (( f ; xeD: *(*)); xeD':h(x)) 

And, in specifying domains, we use the notation low., high to denote the set 
[a \low£a£high). 


‘in the sequel, we use upper-case identifiers to denote (physical) state com- 
ponents and the corresponding lower-case identifier to denote the reality variables 
that model these. 
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2.2. Preserving the Fiction: Updating Reality Variables 

The state of a physical system is changed by a physical process. Typi- 
cally. the changes can be characterized by a set of equations relating the 
current values of various state components to their recent values. We cannot 
expect a physical process to update the reality variables being used in model- 
ing the state of a physical system. And, since the weakest-precondilion cal- 
culus is based on the presumption that all changes to the truth of an assertion 
are the result of program execution, we have no choice but to regard the pro- 
gram itself as performing updates to reality variables. Program statements 
can compute these updates by using the equations that characterize the way 
the physical state components change. 

Consider some physical state component Q(P) being modeled by a 
reality variable q(p), and suppose that as long as no actuator changes during 
some interval from P to P +5, changes to Q are characterized by the follow- 
ing continuous equation. 

(2.1) Q(P+A) = J(Q(P),A) for 0£A£S 

Let (S)a denote a statement whose execution coincides with a change of 5 by 
parameter P. Then, execution of (5)# is equivalent to executing S and, as 
part of the same atomic action, changing p and q in accordance with ( 2 . 1 ). 
This state change is modeled by a program fragment' 

5; p, q :=p+ 5, ( q ; i e p ,.p+ 8: 7(q(p), i-p)) 

Using the weakest-precondition predicate transformers for multiple- 
assignment and statement composition, we obtain the following predicate 
transformer characterization for (S) 8 . 

h'P«S> 8 . R) 

= «wp definition of 

np(S, wp(p, q :=p + 5, (q\ i € p .. p+ 8 : 7(q(p), i-p)),R )) 

= «wp definition of 

WpiS* Rp’&.(qi inp.p+t.ftqfpXi-p))) 

Notice that when the independent parameter 8 in <S ) 8 models the pas- 
sage of time, (5)j is a statement that executes for 8 seconds. The definition 
of wp«S>a, R) then asserts that after executing (S)j the current time has been 
incremented by 8 and all other reality variables have been updated as if 8 
seconds had elapsed. However, our characterization of < 5 )* also allows the 
independent parameter 8 to be a quantity other than time, making it possible 
to reason in the coordinate system best suited for the problem at hand. Also 
notice that, according to our weakest precondition characterization of (S) 5 , 
an ordinary statement S must be regarded as being equivalent to (5)o- This is 
because 

wp((S)o,R) = wp(S,R) 
holds, since 7(q(p), 0)=q(p) according to ( 2 . 1 ). 
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To illustrate the use of wp((S)&, !i) in an actual process-control pro- 
gramming problem, suppose we are interested in controlling the speed of a 
railroad train. Define reality variable v(jc) to be the speed of the train when it 
is at a given position x. From Newton’s Laws of Motion, we know that if the 
train does not accelerate during an interval of 5 seconds, then reality variable 
v can be characterized by the following equation: 

(2.2) v(jc+A) =v(jc) forO£A£v(;t)*5 

Thus, according to our definition for wp((S)t, R), we have the following 
weakest precondition characterization for a statement (S)& that takes duration 
5 seconds and is executed while a train is not accelerating. 

wp((S)s,R) 

= «(2.2) and wp definition for (5)s» 

vyp(5, 

^x+v(x)»8, (v; / € x ,.x+v(x)»8: v(x))) 


2.3. Interacting with a Physical Process 

To have broad applicability, a method for reasoning about process- 
control programs must not restrict the types of sensors and actuators that it 
can handle. Rules for reasoning about sensors and actuators can be derived 
by 

(1) modeling interactions with sensors and actuators by statements that 
read and update reality variables, and then 

(2) using the rules provided for reasoning about ordinary statements to 
derive rules for reasoning about these models. 

As long as reality variables correctly model the physical process, the result- 
ing rules will be sound and can be used to reason about how a control pro- 
gram interacts with the process it controls. 

To illustrate how sensors and actuators are modeled, we return to rail- 
road control. Consider an actuator go (r) and a sensor await(c). Executing 
go(r) causes the train to accelerate/decelerate with some maximum constant 
acceleration ACC (say) until target speed t is reached; execution terminates 
only when the train reaches its target speed, await(c), if invoked while the 
train is not accelerating, delays execution of a program until the train is at 
location c 2 

Define Vlcn(u , t) to be the distance that a train travels while it is 
accelerating from a speed u to target speed r. 

Vlen(u, t) = |(u 2 -r 2 )/(2*ACC)| 


2 If go(t) is the only actuator that can cause acceleration, then the condition that 
await(c) is never executed while the train is accelerating is equivalent to stipulating 
that a train is controlled by a single sequential p rogr am . 
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Define Vat(u, t, x) to be the speed of a train after having traveled x meters. 
0 ZxZVleniu, t), from the point at which it started accelerating from speed u 
to t: 


Vat(u, t,x) 


Vu 2 +2*xMCC if u<t 

* Vu 2 -2*xMCC if u > t 
u if r=u 


The effect of executing go(r) can be modeled as an update to reality 
variables x and v. The value of x is increased by V7en(v(x), r) and the 
domain of v is extended to include x .. x-t- Vlen(y(x), t ): 

go (r): x, v :=x+Vlert(v(x), t), 

(v; /ex .. x+V7en(v(x), r) : Vat{v(x ), t, l—x)) 

This multiple-assignment statement model provides a basis for calculating 
wp(go(r), R): 

wp(go(r), /?) 

= « model of go(f)» 

wp(x, v :=x+V7en(v(x), r), 

(v; lex ..x+Vlen(y(x), t ): Vat(v(x), t, l-x )), R) 

= «wp definition of 

^xVW<n(»(j), [), (v; / « x ..z+W Wn(v(x), iy. Va/ (»(*), l, /-*)) 

Similarly, await(c) can be modeled by an alternative command: 
await(c): ifx£c aO<v(x) — »x, v :»c, (v; le x ..c: v(x)) fi 

Our model for await(c) updates reality variables x and v if x£c and 0<v(x) 
hold; otherwise, it delays forever. Using the weakest precondition for if, we 
can calculate a weakest precondition predicate transformer for await(c): 

wp(await(c), R) 

= «model of await(c)» 

np(ifx£c a0<v(i)-4i,» :=c, (v; lex .. c : v(x))fl, R ) 

= «wp definition of if» 

x£c a 0<v(x) 

a (x£c aO<v(x) => wp(x, v :*c,(v; le x..c: v(x)), R)) 

= «wp definition of and predicate logic» 

xZc A0<v(x)A/?f;f v: 

3. An Example 

Other than the extensions mentioned above, the methodology of [2] and 
[3] for deriving ordinary sequential programs can be used, unchanged, for 
deriving sequential process-control programs. In this section, we illustrate 
that methodology with a simple railroad-control problem. 

Railroad tracks are typically partitioned into segments, called 
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blocks. Each block i, has an associated starting location b t and end- 
ing location 6,+j , where b, <b lJr i , and a range of permissible speeds 
mn, .. mx,, where 0 £mn,- <mxj. Desired is a program to control the 
speed of a point train 3 so that it travels from bo to b H , maintaining 
safe speeds along the way. Use go(r) and await(c), as defined 
above, for interactions between a single sequential control program 
and the train. 

First, we formalize the problem. The train has made a safe passage from 
location a to b provided the following holds. 

Scrfe(a,b)\ a..b<zdom(v) 

a (V/: a<.l<>b : bi*l£b M =* m/i, £v(/)£mx,) 

The first conjunct of Safe(a,b ) asserts that the train has actually traveled 
from a to b, and the second conjunct asserts that the train’s speed satisfied 
the restrictions associated with each block it occupied. Using Soft (a, b), we 
can specify the above railroad control problem in terms of weakest precondi- 
tions: 

(3.1) x=bo a v=(; bo'.vo) => wp(S, Safe(bo, bn) A x ~b K ) 

This formula constrains S to be a program that terminates with the train at 
location b„ after having traveled at safe speeds to get there, provided S is 
started with the train at location b 0 traveling with speed v 0 . 4 

3.1. A First Try 

Having formalized the specification for a correct control program 5, we 
now proceed with the derivation. The universal quantifier in conjunct 
Safe (bo, b n ) of the result assertion is a tip-off that S should be structured as a 
loop. Thus, we employ a standard hueristic from [2] — replacing a constant 
by a variable — and derive a loop invariant from the result assertion. Replac- 
ing n in the result assertion by a new program variable h (for "here’’) we get: 

/: Safe(bo,bh) a x-b * a 0£A£n 

Since / a h -n implies result assertion Safe(bo, b„) a x-b n , we conclude that 
the loop guard must be h*n (or something that implies h *n) and conjecture 
that S has the following structure: 


3 Assuming a point train is not fundamental. It merely simplifies some of the 
derivation that follows. By using a configuration space transformation [4], the con- 
trol problem for a length L train can be transformed to a control problem for a point 
train on a track with additional blocks. 

4 If the conjunct x=b n is omitted from the result assertion, then it would be per- 
missible for control program S to terminate long after the train had passed point b H . 
We have deemed such behavior unacceptable and so our specification prohibits it 
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5: 5, {/} 

do h*n -4 {/ a h*n) S 2 {/} od {A=/ia/} 

{Sctfe(b 0 , b H )) 

Program 5 will satisfy its specification provided we find statements 5, and 
02 that satisfy the following specifications. 

(3.2) x = /?o a v =(; 6 0 :v 0 ) => upCSj . /) 

(3.3) / a h => wp(S 2 , /) 

Formula (3.2) is the specification for the loop initialization; (3.3) is the 
specification for the loop body. 

According to specification (3.2), 5, must establish /. Observe that an 
easy way to establish / is by setting A to 0. So. we use wp to calculate an 

assertion that must hold before executing h 0 in order for / to hold after- 
wards. 


h v(h ■= 0 , /) 

= «wp definition of 

(S<rfe(b 0 , b h ) a x—bfr a OZh £*)$ 

* textual substitution* 

Safe(b 0 ,bo) a x=b o 
= «definitionofSqfir(a, A)» 

b 0 e dom{y) a mn 0 £v(bo)£mx o a x*A 0 

Notice that x=6 0 a v=(; 6 0 :v 0 ), the antecedent of specification (3.1) for S, 
implies wp(h :=0, /) only if mn 0 £v 0 £mxo. Thus, executing A :=0 estab- 
lishes the loop invariant only under certain conditions— the initial speed of 

the train must be safe for travel in block b Q . We identify this requirement 
explicitly. 

Assumption AS 1. mn 0 £v 0 <mxo 

In retrospect, this requirement should not be surprising. It is worth noting, 
however, that this implicit assumption was exposed simply by adhering to a 
rigorous calculus in deriving the program. Including this assumption in the 
program we have developed so far, we gee 

S: [x—bo a v=(; *> 0 :vo)aAS/} 

h .-O (/: S<tfe(J>Q,b k ) a x=b h a 0£A£/i) 
do h* n {/ aA*/i) S 2 {/} od {A=/ia/} 

[Safe(.b 0t b H )) 

We now refine S 2 , the body of the loop. Based on our choice of guaiti. 
we know that the loop will terminate when h equals n. Initially, A is 0. Thus, 
for S 2 to make progress towards termination, A must be increased; and for S 2 
to satisfy specification (3.3), S 2 must reestablish /. To investigate the feasi- 
bility of increasing A by 1 , we calculate wp(h ;= A + 1 , /). 



wp(h := A + 1 , /) 

«*>p definition of ":="* 
(S(rfe{bQ,b k ) a x=b h a 0Zh£n)i +l 
•textual substitution)* 


Sofe{b Q , b h+l )*x=b H+l aOSA + 1£/i 

c . *? (5 ^ (a ’ c > * (&?fc(a. 6 ) a Soft (A, c )))» 

Safe(b 0 ,b h ) a Sqfe(b h , b^) A x=6* + , a 

Since l Ah*n holds at the start of S 2 , we know that the firet and last rnn 

CttT* : ’* +M) to,d «" * w« 

ar range for the remaining conjuncts to hold. 


Stfc ( bi ,, b ^+ i ) a x = b h+y 

•definition of Safe{a , 6)» 
•• ^*+iCtio/n(v) 


a (V/: b h zizb h+l : biZlzbi+y 

=> mniZvCDZntXi) A 1%, 

«-*-o* +) =^£ 0 •6A + icdIom(v)» 

(V/: b K ZlZb k + y : bi*t*b M =*mn 4 Sv(/)^mx,) a x=A a+i 
• predicate logic* 

(V/. b h £l<b k+x : bjZlZbi+i => m/i,£v(/)£mx l ) 

a maxCmnA.mn^OivC^o^minC/nxA.mr^,) A x=f>* +1 

ex^r^rrj,^ 1 is -* - “ Ni * * — * 


(3.4) 


(3.5) 


Hp(await( 6 * +1 ), (3.4)) 

= «wp calculus* 

X ^A+| A 0<v(x) 

A ((V/. b h Zl<b h+l : biZlZbi+x =*mni£v(l)£mxi) 

a max(m/i*. mn A+1 )^v(6 A+ ,)^niirt(mx*, mx h +,) 

A X ~ * +l ^Ci.(v: /€ Vi: V(x)) 

•textual substitution and simplification* 
x ^a+i a 0<v(x) 
a (V/: b h Zl<b h + x : b^lSb M => 

A s " W| ^ (v; / 6 X .. 6* +1 : v(x)X/) £ ffU;) 

* (v; / € x .. £>*+,: v(r)X6* +I ) 

£min(mr Al mx* +1 ) 

* T by What is ^ hold at the stare of 

the state from n ^, mUSt iJf reforc em Ploy additional statements to transform 

junct of (Ts)cT^ f *' h * n t0 0nC Satisfyin « < 3 - 5 >- final con- 

is safe and is arta' m k S ^ by executin * ***>. where t is any speed that 
d attainable by accelerating from v(b h ). That is. x must satisfy: 

(3.6) max(m/« A .mn A+1 )ixSmin(mx A .mx* +1 ) 

* Vl*n( V (b h \x)Zb h+l -b h 
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Nothing stated thus far implies that it should be possible to accelerate 
from any safe v(bt,) to a safe v(6*+i) in at most a distance of b k+ \ —b k , and 
so without making further assumptions about speed constraints, our control 
problem is unsolvable. We have uncovered another hidden assumption 
required to control a train: 

Assumption AS2. (Vi, r: 0<i <n a max(mn,_i, mrt,)£s£min(mr,-i, mxi): 

(3r': max(m/ij, m/i l+ i)Sj'Smin(mx,, mx (+ i): 

Vlen(s, s^Zbi+i-bi))) 

Henceforth, we assume that speed constraints for blocks do satisfy AS2. (It 
is not difficult to prove that any control problem for which there is a safe 
path from b 0 to b n can always be reformulated as one with more restrictive 
minimum and maximum speeds satisfying AS2.) 

A target speed x satisfying (3.6) can now be computed as follows. 
First, due to the definition of Vlen(u, t), the set of attainable speeds s both 
safe and unsafe — starting from position b k is characterized by. 

Vv(b*) 2 -2MCC *(b*+i —6*) Zs S ^v(b k ) 2 +2MCO(b*+i -b k ) 

Second, the set of safe speeds s for location b k+ \ is given by: 

max(m/tj,, mn* + i) £ s £ minOnx*, mx*+i) 

The intersection of these sets, therefore, is the set of safe and attainable 
speeds; the maximum of this intersection is the greatest safe speed time is 
money for a railroad. 

x = min(Vv(b*) 2 +2MCC*(h*+i”^*)» ***** 

Using this value of x for the target speed ensures that the final conjunct of 
(3.5) wiU hold. 

The penultimate conjunct of (3.5) now is implied by our choice of x 
and Safe(b 0 , b k ). Thus, our only remaining obligation is the truth of the 
second conjunct of (3.5), 0<v(x). Recall that OSm/i.cmx, holds, by 
assumption. Thus, for all i, mx j*0 and so successive values of t are each 
non-zero. Provided v 0 *0, we can strengthen the loop invariant to include 
0 < v(x) as a conjunct This results in the following program. 
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5: [x=bo a v=(; £ 0 :v 0 ) a AS1 a 0<v 0 a AS2) 
h -0 

{/: Safe(b 0 ,b k ) a x=b h a 0£/i£n a 0<v(x)} 
do h*n — » (/ a /i*n) 

S 2 : r := min(s^rt(v(6*) 2 +2MCC*(&* + i-&A)). 
mx A , mx* +1 ); 

go(0; 

awaitC^+i); 
h :=/i + l 
(/} 

od [h=n /\ I) 

[Safe® 

As the final step of the derivation, we delete references to reality vari- 
ables from program statements. Recall, reality variables are auxiliary and, 
therefore, may not affect program execution. The only reference to a reality 
variable from within statements in the program above is the expression v(fe^). 
We can maintain this value in a program variable vel by strengthening the 
loop invariant and adding assignments after each go statement. Making 
these changes results in the following control program; it solves the railroad 
control problem. 

S: {x=bo a v=(; b 0 :v 0 ) a AS/ aO<v 0 aAS2} 
h :=0; vel:=v 0 

(/: S<rfe(b 0 ,b h ) a x=b h a OZhZn a 0<v(x) 
a vel=v(b h )) 
do h*n — ► (/ a /i*n) 

S 2 : t := mm(sqrt(vel 1 +2*ACC*(b),+i- b/,)), 
mx h , mx* + i); 

go(f); 
vel :=r, 
awalt(b*+i); 
h \=h+l 
{/) 

od [h-n a /) 

{Safe&o, b H )) 

3.2. An Improved Control Program 

Although correct, the control program just derived does not always per- 
mit a train to travel as quickly as possible. Modifying the derivation to max- 
imize train speed is not difficult, however. First, we rewrite (3.4) as follows: 

(V/: b h <l<b M : b&libi+i => mn,£v(/)Smx;) 
a max(m/i/,_i , /nn*)Sv(6*)^min(mx*_t , mx h ) 
a max(mrt*, mn/ k+ i)Sv(b* + i)^ m i n ( mjc ** ^a+i) A x ~bh+i 
Then, rather than allowing the final conjunct to drive the derivation (as it did 
above), we concentrate on the penultimate conjunct. The loop body that 
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results from this strategy is: 

S 2- go(r i ); 

await(b Jl + l -V/en(r l ,/ 2 )); 
go(t 2 ): 

h :=h + 1 

where t j and t 2 are the largest speeds satisfying: 

Vlen(v(b h ), ty)+Vlen(t \ , t 2 )<,b h +y -b h a mn h Sr, Zmx k 

a max(m/i*, mn A+ i)^/ 2 ^niin(/ru*, 

Computing values for t , and t 2 and using this new S 2 as a loop body, we get 
the following revised control program. 

S : U=&oav=(; & 0 :vo) a AS1 a 0<v 0 a AS2) 
h := 0; vel := v 0 

{/: Sctfe(b 0 ,b h ) a x=b h a OZhZn a 0<v(x) 
a vel=v(b H )) 
do h*n —> {/ a h*n) 

S 2 - *i :=min(mx*, 

sqrt(.vel 2 +2*ACC*(b h + l -b h )), 

1 vel 2 

sqrti— — + — +*CC*(b h + x -b h )))- 
t 2 :=min(r, t /ru A+1 ); 
go<f,); 

await0 A+1 ~Vlen(t i , r 2 »; 

go(r 2 ); 

vel :=t 2 ; 
h :»A + 1 
{/} 

od [h=n a /} 

(Safeco, &„)} 

4. Discussion 

We were pleased to discover that only minor modifications were 
needed in order to employ Dijkstra’s weakest- precondition calculus in deriv- 
ing sequential, real-time, process-control programs. Dijkstra’s calculus, 
unfortunately, is based on regarding a program as a relation between sets of 
states and, therefore, does not scale-up to concurrent and distributed pro- 
grams, which are best thought of as "invariant maintained". The extensions 
derived in section 2 for handling the state of a physical process — the contri- 
bution of this paper— do scale up. For example, we have been able to use 
them along with a logic for proving arbitrary safety properties of concurrent 
programs. Proof Outline Logic [5]. 

Second, both of the control programs we developed assumed that 
assignment statements are instantaneous. In reality, executing assignment 
statements does take time, and the state of the controlled process can change 
during that interval. It is not difficult to derive control programs for this 
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more realistic setting. The predicate logic details become a bit messier as do 
the constants, but nothing about the structure of the derivation or resulting 
programs changes. 

Reality variables are history variables — they encode in the current pro- 
gram state information about past system states. Using history variables for 
reasoning about programs is usually a bad idea, because it introduces distinc- 
tions that should be irrelevant. The current state — not how it was 
computed — should be of concern when reasoning about what a program will 
do next. In reasoning about process-control systems, however, one has no 
choice but to employ history variables of some sort This is because the past 
instants for which the state of a physical process is defined is a strict superset 
of the past instants for which the state of a control program is defined. A 
program implements a discrete transition system, while a physical process is 
likely to implement a continuous transition system. History variables allow 
us to reason about all of the behavior of the physical process, including those 
states that exist while the program state is in transition, hence undefined. 
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provided helpful comments. 

References 

[1] Clint, M. Program proving: Coroutines. Acta Information 2, 1 (1973), 
50-63. 

[2] Gries, D. The Science of Programming. Springer- Veriag, New York, 
1981. 

[3] Dijkstra, E.W. A Discipline of Programming. Prentice Hall, N.J., 
1976. 

[4] Lozano-Perez, T. Spatial planning: A configuration space approach. 
IEEE Trans, on Computers C-32, 2, 1983, 108-120. 

[5] Schneider, F.B. and G. R. Andrews. Concepts for concurrent program- 
ming. In Current Trends in Concurrency. (J.W. de Bakker, W.P. de 
Roever, and G. Rozenberg, eds.) Lecture Notes in Computer Science, 
Volume 224, Springer-Verlag, New York, 1986, 669-716. 


- 12 - 




